It is known to provide a data processing apparatus having a multi-threading architecture, in which a processor of the data processing apparatus has access to a plurality of different sets of registers, each register set being associated with a different execution thread of the processor. Such a multi-threading architecture at the hardware level (i.e. through the provision of multiple register sets) provides significant performance improvements for the data processing apparatus, since by increasing the amount of processing work available at any point in time, this tends to increase the amount of useful work that can be performed by the data processing apparatus at that time. For example, when a particular execution thread reaches a point where a significant delay is incurred, for example due to the requirement to perform a fetch of a data value from memory, then the processor can switch to another execution thread at that time with minimal delay, due to the fact that the execution context of that other execution thread is already available in the associated register set provided for that other execution thread. As used herein, the term “execution context” refers to the architectural state associated with a given execution thread, typically most if not all of this architectural state being provided by the contents of the register set associated with that execution thread, and hence for example the execution context will identify certain control parameters applicable to the processor when executing that execution thread, and certain data values accessible by the processor when executing that execution thread.
As another example of where such a multi-threading architecture can provide significant performance improvements, in a multi-issue apparatus having multiple functional units, instructions from a second thread can be run on functional units that are not currently needed by a first thread and would otherwise be idle. As yet another example, the processor could run alternating threads on alternating clock cycles to diminish the effect of register read delays, etc.
In addition to the above multi-threaded architectures, there also exist certain single-threaded architectures, where the processor only has a single execution thread. Whilst in such a single-threaded architecture the processor will normally use a single register set, it is sometimes the case that certain registers within the register set are “banked”, i.e. duplicated, such that when transitioning from a certain mode of operation to another mode of operation, certain architectural state can be retained within the banked registers associated with the mode being exited, such that on a return to that mode those items of architectural state are readily available. Such single-threaded architectures that employ banked registers will be referred to herein as “single-threaded banked architectures”.
One particular example of a data processing apparatus that employs such a single-threaded banked architecture has a processor which is operable in a plurality of modes and either a secure domain or a non-secure domain. The plurality of modes include at least one non-secure mode being a mode in the non-secure domain and at least one secure mode being a mode in the secure domain. The processor is operable such that when executing a program in a secure mode the program has access to secure data which is not accessible when the processor is operating in a non-secure mode. In such a system, a certain number of the registers are banked so that when the processor is operating in a non-secure mode, one of the banked group of registers is used, whilst when the processor is operating in a secure mode, the other banked group of registers is used. The remainder of the registers in the register set are non-banked, and are accordingly shared between both domains. Hence, when transitioning from the secure domain to the non-secure domain, such non-banked registers would typically be flushed so that any secure data associated with that secure domain is not accessible in the non-secure domain. In the following text, this particular example of a single-threaded architecture employing both a secure domain and a non-secure domain will be referred to as a TrustZone (TZ) architecture. An example of a data processing apparatus having such a TZ architecture is described in GB-A-2,402,785.
When adopting a single-threaded banked architecture such as the TZ architecture, this increases the size and cost of the data processing apparatus since extra silicon area is provided to contain the banked registers. Any multi-threaded architecture would also require additional registers to be provided to accommodate the additional execution contexts applicable to the multiple execution threads.
Whilst it is desirable to use data processing systems employing multi-threaded architectures, due to the performance benefits that can be realised, it is also desirable to support within such data processing systems software developed for single-threaded banked architectures such as the above-mentioned TZ architecture, since much effort will have been invested in producing robust, certified software for such architectures. However, a multi-threaded data processing apparatus already requires additional register sets to be provided to accommodate the multiple execution contexts, and if each of these execution contexts also has to provide the extra banked registers required by certain single-threaded banked architectures such as the TZ architecture, this will further increase the size and cost of the data processing apparatus and hence make that data processing apparatus less attractive, particularly for applications which do not make use of the single threaded banked architecture.
Accordingly, it would be desirable to provide a multi-threaded data processing apparatus which provided a more efficient mechanism for supporting software written for single-threaded banked architectures, for example a multiple domain architecture such as the TZ architecture.